802.1x protocols evolve from the standard Wireless Local Area Network (WLAN) protocols, 802.11. A main objective of 802.1x protocols is to provide a solution to access authentication of WLAN users. 802.1x protocols have currently been adapted for access control in common wired Local Area Networks (LANs). For example, Microsoft's Windows XP, and devices manufactured by Cisco and Huawei-3Com now support 802.1x protocols. 802.1x is primarily a set of authentication protocols, i.e., methods and policies for authenticating users. 802.1x is port based. The term “port” may refer to an actual physical port, or a logical port like a Virtual Local Area Network (VLAN). In the case of WLAN, a port may be a channel.
The goal of 802.1x authentication is to determine whether a port can be used. For a port, if authentication is successful, the port is set to be open, allowing all messages to pass; otherwise, the port remains closed, allowing only Extensible Authentication Protocol (EAP) messages to pass. The structure of 802.1x authentication involves three parties: a supplicant, an authenticator, and an authentication server. EAP messages are transmitted transparently by the authenticator to the supplicant or the authentication server; hence, the structure of 802.1x authentication supports only point-to-point authentication.
FIG. 1 is a block diagram of the structure of a TePA-based access control method in the prior art. In order to realize encapsulation of the three-party authentication protocol and transmission control of network data (i.e., transmission control of authentication protocol data and application service data), a TePA-based access control method (which is used in the Chinese WLAN standard) has been proposed and has a structure as shown in FIG. 1. Specifically, PAE refers to a port authentication entity. The supplicant PAE, the authentication access controller PAE and the authentication server transmit Tri-element Authentication Extensible Protocol (TAEP) packets. The supplicant PEA and the authentication access controller PAE also perform control of the controlled port. TAEP packets have a format similar to that of the EAP packets, but TAEP has a hierarchy model different from that of EAP.
The format of a TAEP packet is illustrated below:
Code (8 bits)Identifier (8 bits)Length (16 bits)Data
where,
Code:
the Code field has a length of 1 byte, representing the type of the TAEP packet:                1 Request        2 Response        3 Success        4 Failure        
Identifier:
the Identifier field has a length of 1 byte, for matching the Request packet with the Response packet;
Length:
the Length field has a length of 2 bytes, representing the number of bytes of the whole TAEP packet, i.e., the sum of the lengths of all the fields including Code, Identifier, Length and Data;
Data:
the length of the Data field is variable, e.g., zero or more bytes, and its format is determined by the value of the Code field.
The multiplex model of TAEP is illustrated below:
Authentication Authentication Supplicantaccess controllerserverTAEP authentication TAEP authentication TAEP authentication methodsmethodsmethodsTAEP peer layerTAEP authentication access TAEP peer layercontroller layerTAEP layerTAEP layerTAEP layerLower layerLower layerTransmission Transmission layerlayer
TAEP messages are exchanged according to the following steps:
a) The authentication access controller sends a Request packet to the supplicant, to request initiation of authentication. The Request packet includes a type field indicating the type of the requested. Specifically, the type of the requested is Identity which represents an identity.
b) In response to a valid Request, the supplicant sends a Response packet to the authentication access controller. The Response packet includes a type field corresponding to the type field in the Request packet, and the identity of the peer is included in the message.
c) The authentication access controller sends a Request packet to the authentication server. The Request packet includes a type field indicating the type of the requested. Specifically, the type of the requested is Third Party (TP) Authentication which is used to request the type of the authentication method from the authentication server.
d) The authentication server sends a Request packet to the authentication access controller. The Response packet includes a type field corresponding to the type field in the Request packet.
e) The authentication access controller selects an authentication method according to the type of the authentication method returned by the authentication server, to initiate authentication. A Request packet is sent to the supplicant, and a Response packet is sent by the supplicant to the authentication access controller. The interaction with Request packets and Response packets continues as needed. The authentication access controller sends Request packets to the authentication server, and the authentication server sends Response packets to the authentication access controller. The sequence of Request packets and Response packets may continue as desired. The authentication access controller is responsible for retransmission of Request packets.
f) The interaction may continue until the authentication access controller determines that it can not authenticate the supplicant, in which case the authentication access controller sends a Failure packet to the supplicant; or, determines that successful authentication is completed, in which case the authentication access controller stops sending Request packets to end the message interaction or sends a Success packet to the supplicant.
The steps c) and d) are optional. In some cases, when the authentication method is pre-determined, or when the authentication method and the identity are determined in other ways, the steps c) and d) are optional.
With the development of informatization, problems of malicious software such as viruses and worms are growing. Currently, more than 35,000 forms of malicious software have been found, and more than 40,000,000 computers are infected each year. To this end, the Trusted Computing Group (TCG) has developed a network access specification based on Trusted Computing, i.e., Trusted Network Connect (TNC), hereinafter referred to as TCG-TNC, which includes an open architecture for endpoint integrity and a set of standards that ensure secure interoperability. As shown in FIG. 2, a schematic diagram of a TCG-TNC architecture in the prior art, the policy enforcement point in the architecture is at the edge of the network, and the access requestor does not perform platform authentication on the policy enforcement point; hence, the policy enforcement point can not be relied upon. To solve this problem, a Tri-element Peer Authentication (TePA) based TNC architecture has been proposed.
Reference is made to FIG. 3, a schematic diagram of a TePA-based TNC architecture in the prior art. In the TePA-based TNC architecture, the network access control layer is a traditional network access technology mechanism, which performs the tri-element peer authentication protocol (a three-party authentication protocol) to realize mutual user authentication, and uses the TePA-based access control method discussed above for encapsulation of the user authentication protocol and transmission control of network data. However, besides the network access control layer, the TePA-based TNC architecture as shown in FIG. 3 also includes an integrity measurement layer and a trusted platform evaluation layer, which execute a platform authentication protocol to perform identification, authentication and evaluation of platform component information. In addition, the platform authentication protocol data also need to be transmitted in the network access control layer, and are allowed, blocked or isolated (as compared with the access result in a traditional network access technology which is to allow or to block) according to an access result generated from the platform authentication result. Therefore, the TePA-based access control method discussed above is not suitable for a TePA-based TNC architecture. Hence, it is desired to establish an access control method for a TePA-based TNC architecture.